Block settings that restart the app when in form entry #6488
Conversation
| // there is no formController -- fire MainMenu activity? | ||
| Timber.w("Starting MainMenuActivity because formController is null/formLoaderTask not null"); | ||
| startActivity(new Intent(this, MainMenuActivity.class)); | ||
| throw new IllegalStateException("Null formController!"); |
There was a problem hiding this comment.
This (and the below case) don't have tests and as far as I'm aware, we don't know how they happen. Crashing means we don't have to deal with form session/lock clean up, and I actually think it's a better experience now that we show the crash message on the next relaunch than mysteriously returning to the Main Menu without warning.
|
|
||
| if (inFormEntry) { | ||
| findPreference<Preference>(PROJECT_MANAGEMENT_PREFERENCE_KEY)!!.also { | ||
| it.isEnabled = false |
There was a problem hiding this comment.
Could it be made clearer that these settings are disabled? The visual effect feels off - the title isn't grayed out, only the summary, which makes it hard to notice the difference at first glance.
There was a problem hiding this comment.
Totally agree! We can tweak that if we need, so I'd vote we go with this for now and follow up if we're still unhappy with it.
..._app/src/main/java/org/odk/collect/android/preferences/screens/ProjectPreferencesFragment.kt
Outdated
Show resolved
Hide resolved
..._app/src/main/java/org/odk/collect/android/preferences/screens/ProjectPreferencesFragment.kt
Show resolved
Hide resolved
|
Should "project management" (in settings) also be blocked during form entry? |
Yes. Any settings that allow you to return to the main menu should. In project management you can reset the project, reconfigure with QR code etc which all return to the main menu. |
|
Tested with Success Verified on device with Android 15 Verified cases:
|
|
Tested with Success Verified on device with Android 10 |
Closes #6482
I've also cleaned up a couple of cases in
FormFillingActivitythat would return to the main menu in rare states.Why is this the best possible solution? Were any other approaches considered?
As discussed in the issue and elsewhere, we decided to go with blocking these settings during form entry for now as reworking locking would be better to after #5420.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
The main things to check here are that the user is not able to access settings that reproduce the bug.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest(or./gradlew testLab) and confirmed all checks still passDateFormatsTest